POV-Ray : Newsgroups : povray.programming : Improved intersection routine for CSG-Intersection objects : Re: [OT] Re: Improved intersection routine for CSG-Intersection objects Server Time
6 Oct 2024 14:00:59 EDT (-0400)
  Re: [OT] Re: Improved intersection routine for CSG-Intersection objects  
From: Warp
Date: 13 Dec 2003 21:44:40
Message: <3fdbce98@news.povray.org>
Thorsten Froehlich <tho### [at] trfde> wrote:
> It should not be forgotten that "good OO design" is a far from trivial
> thing.  Especially when it comes down to the ugly little details that look
> great in the UML diagram, but are much harder to implement an second sight

  This is certainly true.

  Thinking that you can make good object-oriented programs after having
been in a UML course is like thinking that you can drive a F1 car right
after you have got your driver's license. However, I'm afraid that too
many people think this way.

  Background theory is extremely important, if not mandatory, but only
experience (lots of it) will give you the qualification. And not whatever
programming experience at free, but expressly object-oriented programming
experience.
  10 years of "hacker" C programming experience will (at least at first)
probably be more a burden than a benefit (even though that experience can
become very handy once you have assimilated good OO principles and got
some experience about it). This is because C teaches very, very bad
habits which are a real burden in good object-oriented C++.

  In the project I'm working at we are at the third generation of our
major file I/O library. It has gone through two complete re-designs
because the previous designs resulted to be cumbersome in practice (even
though they looked nice in paper). The current third design is starting
to look like what it should. :)

  This is a very common phenomenon I have noticed: In any bigger project
the first OO design of the system will most probably be flawed and will
probably need at least one major re-design with more practical experience
before it becomes usable.

> ... especially if the primary goal is raw performance the temptation to
> "just use C" is always around.  And in the end it will always be the wrong
> decision.

  The sad thing is that sometimes the "C-way" will be slower and less
efficient than the "C++-way". For instance, compare C and C++ strings.
(Most operations are much faster in C++, not to talk about C++ strings
being a lot more secure with regard to memory leaking. C++ strings are
also a lot easier to use.)

  (It's really sad that C++ streams are still slower than C streams in
most compilers. When will they make an implementation which is at least
as fast?)

> On the other hand, to master all C++ features well takes years of practical
> experience and a gentle growths of abilities:  It would be irrational to
> expect to be able to teach anybody a language as complex as C++ from any
> number of books or in a classroom.

  Some books really help. For instance "Effective C++" and "More Effective
C++"... :P
  (Of course these books are aimed to those who already have experience
about C++ and want to learn more.)

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.